本系列文章已集結成冊與鐵人賽文章差異內容,有以下幾點:
更新至Laravel 8、基礎的PHP重點筆記、加強製作API流程細節、加入程式設計模式,優化、重構程式碼的部分,並且於書籍前面的章節介紹Git。
讓您從製作第一個簡單的API到優化自己的程式碼,分享我的經驗給您,打造自己的最強大腦API,若有興趣的朋友可以參考看看
先強調一下! RESTful API 是一個設計模式,不一定每個需求都會符合這樣的設計,所以還是需要依照專案的需求去做一點調整才不會感覺為了用RESTful API而用RESTful API。
小時候的我(誤)兩年前,設計網站的時候,基本上用ajax拿資料時,我的後端URI命名方式都是很隨意的例如像這樣,以post(文章)資源當範例
甚至會依照前端的畫面,打造專屬的命名 URI
看了眼花撩亂,說老實的我一個禮拜回去看我就已經有點看不出來是什麼功能了!簡單來說就是沒有一個原則。
例如上面的
第一個網址可能有分頁的功能,第二個可能只有讀首頁需要的所有Post 文章資料而已,很難知道這個URI的功能。
如果工作的時程比較短,緊急又壓縮到我做其他事的時間,我乾脆直接做一個新的,所以變得越來越多方法!
想一想這樣不行,也剛好目前手上的案子,進入維護階段,讓我開始想盡任何的辦法優化系統,其中一樣就是打造一組RESTful API。
RESTful API是一種設計模式
基本上會包含 URI \ Object \ Action
HTTP 定義了一組能令給定資源,執行特定操作的請求方法(request methods)。
以 Post(文章) 這個物件舉例
HTTP 動詞 | URI | 功能 | 說明 |
---|---|---|---|
POST | api/v1/posts | 發表一篇文章 | 如果相同請求送第二次,會回傳新的一筆資料,內容一樣只有ID不同。 |
DELETE | api/v1/posts/1 | 刪除ID1 文章 | 如果發送兩次請求,第二次回傳找不到資源的錯誤訊息。 |
PUT | api/v1/posts/1 | ID1資料整筆替換 | 替換 ID1 整筆資料,有點像舊資料的刪除,寫入新的資料。 |
PATCH | api/v1/posts/1 | 更新文件 ID1 部分內容 | 指替代掉部分內容,內容會依照發送請求的資料修改。如果沒有填寫的部分保留舊的資料內容。 |
其他不符合以上類別的動作用 POST
這樣規劃有個好處,看網址就可以知道怎麼找資料,需要抓資料時,就可以比較容易判斷,不會像前面所敘述的,忘記有什麼方法或是不知道那個功能裡面怎麼寫的,日後別人接手也比較好維護。
此篇文章同步發到個人部落格